@sdelamo please check this is ok

@scottslewis Could you please clarify if the fact that mcp-core has compile-time dependency on mcp-json is breaking OSGI (and how) or if you "just" consider that's unnecessary to have a dedicated module for it?

@scottslewis Could you please clarify if the fact that mcp-core has compile-time dependency on mcp-json is breaking OSGI (and how) or if you "just" consider that's unnecessary to have a dedicated module for it?

mcp-json, mcp-json-jackson2, and mcp-core are distributed separately, so in OSGi environments these are loaded as separate bundles, with their own classloaders (separate from other bundle's classloaders and the threadcontextclassloader).

In OSGi the java ServiceLoader (which in non-osgi environments the ServiceLoader uses threadcontextclassloader.getResource to load the JacksonMcpJsonMapperSupplier, and JacksonJsonSchemaValidatorSupplier files from mcp-json-jackson2), cannot find the Jackson*Supplier files, and so the defaults json mapper and the default json validator can't be found/created/set (as per stack traces reported in issue #562).

Moving json api back into mcp-core does not directly fix this problem wrt ServiceLoader. In OSGi, environments, however, it allows the service component runtime to be used instead of the ServiceLoader. In OSGi, instances of these JacksonProvider service can be added to the OSGi service registry on startup. No code changes are necessary, but it is necessary to add OSGI metadata to mcp-core and mcp-jackson2, so that scr can 'see' these JacksonProviders in the OSGi service registry and create defaults on startup.

The upshot is that the ServiceLoader functionality can be usurped by the OSGI service component runtime in OSGI enivronments, since the scr is fully dynamic (not just start/load time as ServiceLoader is), and fully deals with the classloader-per-jar aspect of osgi. The OSGi service registry and scr are well-established, well-debugged, and lightweight. This metadata can be added at build time, and is unlikely to be changed in the future.

Another issue that led to filing this issue: having mcp-core depend upon any other api bundle (mcp-json) really creates a lot of problems for the building/packaging and deployment (and maintenance) of the sdk. For example, it requires two jars (mcp-core and mcp-json) in the most minimal configuration...otherwise mcp-core doesn't work/start at all (needed classes can't be loaded) and so at start/runtime failure can be very hard for consumers to track down. Combine this with the cross-environment ServiceLoader difficulties described above, combined with the fact that mcp-json is a very small number of (api) files, with no dependencies, it seems to me that mcp-json should just be re-absorbed into mcp-core.

@graemerocher @sdelamo FYI we plan to merge this PR unless you strongly object.

Fine by me

oh hold on though it was just a Jackson 3 upgrade one sec reviewing

See related discussion at the end of #562.

@sdelamo Thanks for your feedback, I will have a deeper look tomorrow.

This pull request re-adds jackson-databind to mcp-core, a dependency that consumers of the MCP Java SDK, such as Micronaut MCP, don't need. I hope this does not get merged. I think #742 is the right direction.

No it doesn't...unless something has changed in mcp-core since the pr was created.

The two packages re-added to mcp-core (currently in mcp-json) in the pr are:

io.modelcontextprotocol.json
io.modelcontextprotocol.json.schema

The code in these two packages have zero code references to jackson-databind (or any jackson dependencies at all...see below).

There is this in the mcp-core pom.xml (in my copy before holidays)

		<!-- Used by the HttpServletSseServerTransport -->
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>${jackson.version}</version>
        </dependency>

I'm not sure if this is current (i.e. Used by the HttpServletSseServerTransport comment) though, as when I do a search for 'databind' in all the mcp-core java files this is what I find (again...on my relatively old pr of things).

Here's all the jackson dependencies in mcp-core (again in my old copy).

As you can see, the json code additions do not add any references to jackson code at all. There is one documentation reference in McpJsonMapper, but that can be easily removed if necessary.

FWIW, I'm completely willing to update the pr with the latest of the sdk before merging. There has just been no reason to until now.

I think #742 is the right direction.

I just want to emphasize...as per my explanation above this approach would make the OSGi/other runtime environment problems much worse. This issue and Jackson2 vs. 3 are separate things.

Clearly mcp-core should not have any dependency on com.fasterxml.jackson.core:jackson-databind, but that's not the case on main, so I guess that will not be the case anymore when this PR will be rebased/refined.

Let's maybe first work on #742 and hopefully merge it, then we will ask you to rebase this PR @scottslewis.

Clearly mcp-core should not have any dependency on com.fasterxml.jackson.core:jackson-databind, but that's not the case on main, so I guess that will not be the case anymore when this PR will be rebased/refined.

Let's maybe first work on #742 and hopefully merge it, then we will ask you to rebase this PR @scottslewis.

I've seen that #742 has been effected and so I got all the latest on main and begun the rebasing.

I've run into a snag, however, related to the dependency structure for testing...somewhat alluded to here.

mcp-core has test code that depends upon (now) mcp-json-jackson3...was Jackson2 before #742.

This can be resolved by maven when mcp-json is present...because mcp json is depended upon by both mcp-core and mcp-json-jackson2 and 3. Having mcp-core depend on mcp-json for compile is what this issue/pr recommends changing.

When mcp-json interfaces classes are moved back into mcp-core, however, there is a problem since mcp-json-jackson2/3 then have to depend upon mcp-core for the json API (rather than mcp-json). That creates a circular dependency: mcp-core depends upon mcp-json-jackson2/3 (for testing, not compile) and mcp-json-jackson2/3 depend upon mcp-core (for compile). There may be some maven magic to deal with this dependency structure wrt testing, but I don't know immediately what it is.

FWIW I think things would be much simpler if all tests were taken out of mcp-core...into mcp-tests, or mcp-core-tests or something else. I'm not saying eliminate the tests or anything, just that having test code in a core jar/bundle/library can easily create these sorts of dependency issues in testing.

It also makes the test code harder to maintain because the test dependencies are sort of hidden in the maven build/test meta-data/source code only. For maintaining tests over long periods, I've found it's nice to have them outside of the project that they are testing. That way the dependency structure on the core APIs is very clear, and with minimal dependency...particularly for core...both in source code (maven meta-data) and in runtime metadata (e.g osgi manifest contents in osgi environments).

I've now got a replacement for this pr that updates the source code, the build meta-data, the new osgi meta-data (in pom.xml for mcp-core and mcp-json-jackson2/3). Everything builds (no mcp-json module) and I'm soon going to be testing in osgi as I was with the original pr.

But, whether by maven tricks or moving mcp-core tests out mcp-tests or another new module I'm currently unable to run the tests via maven test. I am able to run tests in IDE, because it resolves the dependencies differently. If there is a maven trick to resolve this please let me know. If moving the tests out of mcp-core makes sense I will assist with that if desired.

But, whether by maven tricks or moving mcp-core tests out mcp-tests or another new module I'm currently unable to run the tests via maven test. I am able to run tests in IDE, because it resolves the dependencies differently. If there is a maven trick to resolve this please let me know. If moving the tests out of mcp-core makes sense I will assist with that if desired.

BTW, another option for dealing with this is to move from mcp-core only the tests that require a json impl to run the test.

But, whether by maven tricks or moving mcp-core tests out mcp-tests or another new module I'm currently unable to run the tests via maven test. I am able to run tests in IDE, because it resolves the dependencies differently. If there is a maven trick to resolve this please let me know. If moving the tests out of mcp-core makes sense I will assist with that if desired.

BTW, another option for dealing with this is to move from mcp-core only the tests that require a json impl to run the test.

this would make the most sense IMO